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REMARKS 

Claims 1-6 and 8-14 stand rejected under 35 USC §1 03(a) as being 
unpatentable over Bickle et al. publication entitled "Differential Effective Lapse Time 
Accumulator (Delta) in view of "How Debuggers Work" by Rosenberg in view of Dreyer 
et al., U.S. Patent 5,657,253. Claim 8 stands rejected under 35 USC §1 03(a) as being 
unpatentable over Bickle and Rosenberg further in view of Hawley et al, U.S. patent 
5,533,192. 

Claims 1, 6, and 1 1 have been amended to more clearly state the 
invention. Claims 3 and 12 have been canceled. 

Applicants' attorney appreciates the time spent and the courtesy shown by 
Examiner during the telephone Interview of June 19, 2007. 

During the telephone Interview of June 19, 2007, the prior art cited 
references were discussed, with respect to claim limitations. More particularly, the 
recited claim limitations of independent claims were discussed with respect to the 
teachings of these prior art references. 

Applicants' attorney agreed to prepare an amendment to further define the 
claimed invention to more clearly state the invention and to distinguish over the 
references of record. 

The present amendment includes amended independent claims 1, 6, and 
1 1 , as amended that further more clearly define the invention respectively including the 
subject matter of canceled claims 3 and 12 to further distinguish over the references of 
record, as discussed during the telephone interview. 
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Reconsideration and allowance of each of the pending claim 1-2, 4-11, 
and 13-14, as amended, is respectfully requested. 

The Bickle et al. publication entitled Differential Effective Lapse Time 
Accumulator (DELTA) discloses a test tool, DELTA, applied to processors whose 
address bus and control signals are defined as conditions and timing measurements are 
taken between address (breakpoint) A and address B or to count the number of times 
the processor executes a particular bus state. The tool allows the measurement of 
system performance in two areas: (1) instruction cycle time measurement and (2) 
program execution time, instruction count and busy state time measurement, under the 
control of a microprocessor 12. The Bickle et al. publication discloses a display terminal 
25 providing an operator interface that is used to enter breakpoint and oscillator 
parameters and to display timing/counting results under the control of the 
microprocessor 12. 

"How Debuggers Work" by Rosenberg discloses hardware debugger 
facilities, at pages 39-40 states the mimimum basic requirements a debugger place on 
underlying hardware are 1 . A way to specify a breakpoint such that when the processor 
reaches this location, execution will stop. 2. A notification system, also called an 
interrupt or a trap, that will notify the operating system (and therey the debugger) that an 
important event has occurred with respect to the running process. 3. The ability to read 
and write directly out of and into the hardware registers when the interrupt occurs; this 
includes the program counter register. 

Dreyer et al., U.S. Patent 5,657,253 discloses an apparatus for measuring 
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and monitoring various parameters that contribute to the performance of a processor 
that includes a pair of programmable event counters for counting any two independent 
events selected from a predetermined list of processor events. A specialized register 
controls the operation of the event counters and also selects the events to be counted. 
The contents of the event counters can be accessed either by a supervisor mode 
program which reads an instruction or through a special access port. 

Hawley et al, U.S. patent 5,533,192 discloses a program debugging 
system having a core unit that includes a plurality of debugger memory areas, each 
uniquely associated with a corresponding one of a plurality of debuggers. The core unit 
responds to an exception condition by selecting one debugger from the plurality of 
debuggers, selection being made by determining which one of the debuggers is 
associated with the program exception. Then, computer state information and 
debugger state information are stored into a selected one of the debugger memory 
areas that is exclusively associated with the selected debugger, and the selected 
debugger is activated. A new debugger may register with the core unit, so that the new 
debugger is added to the plurality of debuggers. The activated debugger may send a 
debugging command to the core unit, which responds by updating debugger state 
information based on the received debugging command, and storing the updated 
debugger state information into the selected debugger memory area. When a debugger 
relinquishes control of the computer, the core unit retrieves the updated debugger state 
information from the selected debugger memory area, and controls the hardware 
resources in accordance therewith. If the updated debugger state information includes 
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an indication that a breakpoint is set, the core unit sets a breakpoint that includes 
information associating the set breakpoint with the selected debugger. When the 
breakpoint is triggered, the core unit identifies from the breakpoint information which of 
the debuggers the breakpoint is associated with, and activates the identified debugger. 

The present invention provides enhanced breakpoint based performance 
measurement. The present invention enables improved timing of a particular function, 
and to count selected programmable events during the execution of a function with a 
breakpoint manager and performance measurement program in accordance with the 
preferred embodiment. The value in a breakpoint instruction in accordance with the 
preferred embodiment essentially selects which of the possible types of events are to be 
counted with the programmable processor event counters. Independent claim 1 , as 
amended, recites the step of providing a debugger breakpoint manager including a 
performance measurement program and a user interface, and enabling a user to specify 
a start bound and an end bound of a performance collection region of a user source 
code and said set of hardware counters. 

Applicants respectfully submit that the total teachings of Bickle, 
Rosenberg, Dreyer et al., and Hawley references, would not enable a user to specify a 
start bound and an end bound of a performance collection region of a user source code, 
nor achieve the programmable hardware counters, nor that the set of hardware 
counters is specified by the user, as taught and claimed by Applicants. 

Applicants respectfully submit that one of ordinary skill in the art would not 
have been led to the claimed invention by the reasonable teachings or suggestions 



-11- 



Serial No. 10/616,525 



found in the prior art, including the Bickle, Rosenberg, Dreyer et al., and Hawley 
references, as now recited in independent claims 1 , 6, and 1 1 , as amended. 

To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references themselves 
or in the knowledge generally available to one of ordinary skill in the art, to modify the 
reference or to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
must teach or suggest all the claim limitations. The teaching or suggestion to make the 
claimed combination and the reasonable expectation of success must both be found in 
the prior art, and not based on applicant's disclosure. See MPEP §2143. 

Applicants respectfully submit that the rejection of claims 1-6 and 8-14 
under 35 USC §1 03(a) fails to meet this first criteria and third criteria. Applicant 
respectfully submits that there is no suggestion or motivation in the Bickle, Rosenberg, 
Dreyer et al., and Hawley references themselves or in the knowledge generally 
available to one of ordinary skill in the art, to modify the reference or to combine 
reference teachings. 

None of the Bickle, Rosenberg, Dreyer et al., and Hawley references 
disclose or remotely suggest the programmable processor hardware counters, and 
providing a debugger breakpoint manager including a performance measurement 
program and a user interface, and enabling a user to specify a start bound and an end 
bound of a performance collection region of a user source code and said set of 
hardware counters, as defined by independent claims 1 and 6 to include processor 
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cycles and cache misses, or by independent claim 1 1 to include processor cycles and 
translation lookaside buffer misses, nor the steps of starting said defined set of 
hardware counters, responsive to said generated start processing instruction; and 
executing the hardware instructions and suspending processing of the hardware 
instructions and stopping said defined set of hardware counters, responsive to 
executing said end breakpoint instruction, and enabling a user to specify a start bound 
and an end bound of a performance collection region of a user source code and said set 
of hardware counters, as taught and recited in each of the independent claims 1 , 6, and 
11, as amended. 

Bickle, Rosenberg, Dreyer et al., and Hawley references fail to suggest 
inserting a start breakpoint instruction and a stop breakpoint instruction in hardware 
instructions; executing said hardware instructions and suspending processing of said 
hardware instructions responsive to executing said start breakpoint instruction; and 
responsive to executing said start breakpoint instruction generating a processor 
interrupt for entering interrupt handler instructions and calling breakpoint instructions, 
and that said breakpoint instructions generating a start processing instruction to return 
processing from said interrupt handler instructions to the hardware instructions and 
starting said defined set of hardware counters, responsive to said generated start 
processing instruction, as taught and claimed by applicants. 

The Examiner acknowledges that Bickle does not disclose suspending 
processing of said hardware instructions responsive to executing said start breakpoint 
instruction. Rosenberg teaches that mimimum basic requirements a debugger place on 
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underlying hardware are a way to specify a breakpoint such that when the processor 
reaches this location, execution will stop, a notification system, also called an interrupt 
or a trap, that will notify the operating system (and therey the debugger) that an 
important event has occurred with respect to the running process, and the ability to read 
and write directly out of and into the hardware registers when the interrupt occurs; this 
includes the program counter register. Rosenberg and Dreyer also fail to suggest 
executing said hardware instructions and suspending processing of said hardware 
instructions responsive to executing said start breakpoint instruction. The references of 
record, including Bickle, Rosenberg, Dreyer et al., and Hawley fail to suggest these 
recited claim limitations, and further that said breakpoint instructions generating a start 
processing instruction to return processing from said interrupt handler instructions to the 
hardware instructions and starting said defined set of hardware counters, responsive to 
said generated start processing instruction, as taught and claimed by applicants. 

Bickle, Rosenberg, Dreyer et al., and Hawley references fail to suggest 
the programmable processor hardware counters for counting predefined programmable 
processor events including processor cycles and cache misses, as recited in 
independent claims 1, and 6. Bickle, Rosenberg, Dreyer et al., and Hawley references 
fail to suggest the programmable processor hardware counters for counting predefined 
programmable processor events including processor cycles and translation lookaside 
buffer misses, as recited in independent claim 11. 

Bickle, Rosenberg, Dreyer et al., and Hawley references fail to suggest 
providing a debugger breakpoint manager including a performance measurement 
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program and a user interface, as recited in independent claims 1 , and 6. Bickle, 
Rosenberg, Dreyer et al., and Hawley references fail to suggest enabling a user to 
specify a start bound and an end bound of a performance collection region of a user 
source code and said set of hardware counters, as recited in independent claims 1 , 6, 
and 11, as amended. 

Applicants respectfully submit that Bickle, Rosenberg, Dreyer et al., and 
Hawley, considering the total teachings in combination, fail to suggest the subject 
matter and the above recited features of the present invention as set forth in 
independent claims 1 , 6, and 1 1 , as amended. 

Thus, each of the independent claims 1 , 6, and 1 1 , as amended, is 

patentable. 

Dependent claims 2, 4-5, 7-10, and 13-14, as amended, respectively 
depend from patentable claims 1 , 6, and 1 1 , further defining the invention. Each of the 
dependent claims 2, 4-5, 7-10, and 13-14, as amended, is likewise patentable. 

Applicants have reviewed all the art of record, and respectfully submit that 
the claimed invention is patentable over all the art of record, including the references 
not relied upon by the Examiner for the rejection of the pending claims. 

It is believed that the present application is now in condition for allowance 
and allowance of each of the pending claims 1 -2, 4-1 1 , and 1 3-1 4, as amended, is 
respectfully requested. Prompt and favorable reconsideration is respectfully requested. 

If the Examiner upon considering this amendment should find that a 
telephone interview would be helpful in expediting allowance of the present application, 
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the Examiner is respectfully urged to call the applicants' attorney at the number listed 
below. 

Respectfully submitted, 



S-signature by 

_/Joan Pennington/_ 



By: Joan Pennington 
Reg. No. 30,885 
Telephone: (312) 670-0736 

July 3, 2007 



